SQL Server 2008 : Data Encryption

What’s New in Data Encryption

In SQL Server 2000 and earlier, if you wanted to encrypt data in your databases, you usually needed to implement some form of client-side encryption. SQL Server itself did not provide any means of encrypting data at the database level, so all the encryption and decryption occurred in the application itself. This required custom-written applications to encrypt and decrypt the data, and only those applications would be able to view the encrypted data.

SQL Server 2005 introduced the capability to perform column-level (sometimes called cell-level) encryption. This provided the capability to encrypt data within the database itself at the column level. However, this method is still not transparent to the applications and requires changes to the database schema as well as changes to your applications and T-SQL code to include the proper function calls to encrypt and decrypt the data as it is stored and retrieved.

SQL Server 2008 introduces a new form of database encryption: transparent data encryption. TDE allows you to encrypt an entire database without affecting client applications. The purpose of TDE is to prevent scenarios in which the physical media (such as database files or backups) containing sensitive data are stolen and then read by attaching the database files or restoring the backups.

Another new feature in SQL Server 2008 is Extensible Key Management (EKM). EKM enables parts of the cryptographic key hierarchy to be managed by an external source such as Hardware Security Module (HSM), referred to as a cryptographic provider. Encryption and decryption operations using these keys are handled by the cryptographic provider. This allows for flexibility and choice in cryptographic providers as well as common key management.

An Overview of Data Security

Security is important for every product and every business. By following some simple security best practices, you can avoid many security vulnerabilities. This section discusses some security recommendations that you should consider for your SQL Server implementations. Securing SQL Server can be viewed as a series of steps, involving four areas: the platform, authentication, objects (including data), and applications that access the system.

The platform for SQL Server includes the physical hardware and networking systems connecting clients to the database servers. The first step in securing your SQL Server environment is to provide sufficient physical security by limiting access to the physical server and hardware components. To enhance the physical security of the SQL Server installation, you should consider placing the server in a room accessible only by authorized personnel, ideally a locked computer room with monitored flood detection and fire detection or suppression systems. In addition, you should physically secure your backup media by storing it at a secure offsite location.

Next, you need to ensure your system provides sufficient physical network security by keeping unauthorized users off the network by limiting access to the network to authorized users only. Make sure your database servers are installed in a secure zone of your company’s intranet behind a firewall. Do not connect your SQL Servers directly to the Internet. Always make sure there is a firewall between your servers and the Internet and set it up to block all traffic except for that which is required.

Next, you need to ensure that you have secured your operating system and files. SQL Server uses operating system files for operation and data storage. Be sure to restrict access to these files to system administrators only. Use the NTFS file system because it is more stable and recoverable than FAT file systems. NTFS also enables security options such as file and directory Access Control Lists (ACLs) and Encrypting File System (EFS) file encryption.

For your installed SQL Server instances, you can enhance the security of the SQL Server installation by running your SQL Server services under service accounts granted the minimal permissions necessary for operation (do not run under the Windows Administrator account!). These accounts should be low-privileged Windows local user or domain user accounts.

Surface area reduction is also an important security measure. Surface area reduction helps improve security by providing fewer avenues for potential attacks on a system. In addition to running services under “least privilege” accounts, this measure also involves stopping or disabling unused components.

You should also enhance the security of the SQL Server instances through limiting the individuals, groups, and processes granted access to SQL Server and appropriately limiting access to the databases and objects the database contains. One way is to require Windows authentication for connections to SQL Server. If you are using SQL Server authentication as well, you should be sure to enforce password policies that require strong passwords and password expiration for all SQL Server logins.

Even if you follow the recommendations presented here for securing your environment, you still can be vulnerable to access control problems. Encryption provides another way to enhance security by limiting data loss even in the rare occurrence that access controls are bypassed. For example, if a malicious user hacks into the database host computer and obtains sensitive data, such as credit card numbers, that stolen information might be useless if it is encrypted.

An Overview of Data Encryption

Encryption is the process of obfuscating data by the use of a key or password. This can make the data useless without the corresponding decryption key or password. Encryption does not solve access control problems. However, it enhances security by limiting data loss even if access controls are bypassed.

Encryption is actually the conversion of readable plaintext into ciphertext, which cannot be easily understood by unauthorized people. The concrete procedure of carrying out the encryption is called an algorithm. Decryption is the process of converting ciphertext back into its original form so it can be understood. Both encryption and decryption require a key, which must be kept secret because it enables the holder to carry out the decryption.

There are two primary methods of encryption: symmetric key encryption and asymmetric key encryption. Symmetric key encryption uses the same key for both encryption and decryption. Asymmetric key encryption, also called public-key encryption, uses two different keys for encryption and decryption, which together form a key pair. The key used for encryption is called a public key. The key used for decryption is referred to as a private key.

Symmetric key encryption is inherently less secure because it uses the same key for both encryption and decryption operations, and the exchange of data requires transfer of the key, which introduces a potential for its compromise. This can be avoided with an asymmetric key because individuals encrypting and decrypting data have their own, separate keys. However, asymmetric encryption is based on algorithms that are more complex, and its impact on performance is more significant, making it often unsuitable in scenarios involving larger amounts of data. However, it is possible to take advantage of the strengths of both methods by encrypting data with a symmetric key and then protecting the symmetric key with asymmetric encryption.

One solution to the dilemma of key distribution is to use digital certificates. A certificate is a digitally signed piece of software that associates a public key with the identity of the private key owner, assuring its authenticity. There is an inherent problem with this approach—namely, how to assure the identity of the certificate issuer. To resolve this issue, Microsoft provides a number of trusted certificate authorities (known as Trusted Root Certification Authorities) with the operating system. These certificate authorities are responsible for verifying that organizations requesting certificates are really what they claim to be.

Typically, the algorithms used for encryption are industry standard, such as the Advanced Encryption Standard (AES). The fact that the algorithms are published doesn’t make them weaker, but rather helps ensure they are strong and robust. Because these algorithms have been reviewed by thousands of experts around the globe, they have stood the test of time. SQL Server 2008 allows administrators and developers to choose from among several algorithms, including DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, 128-bit RC4, DESX, 128-bit AES, 192-bit AES, and 256-bit AES.

• Strong encryption generally consumes more CPU resources than weak encryption.

• Long keys generally yield stronger encryption than short keys.

• Asymmetric encryption is stronger than symmetric encryption using the same key length, but it is slower.

• Long, complex passwords are stronger than short passwords.

• If you are encrypting lots of data, you should encrypt the data using a symmetric key and encrypt the symmetric key with an asymmetric key.

However, what really protects your data from third parties is not so much the algorithm but the encryption key, which you must keep secure. Keys must be stored securely and made available only on a need-to-know basis. Ideally, authorized people or systems should be able to use but not necessarily have a copy of the key. It’s also a security best practice to implement key rotation, changing keys periodically in case a key has been compromised. For greater key security, you can also make use of Extensible Key Management, allowing keys to be managed by an external source such as Hardware Security Module.

SQL Server 2008 provides support for not only encryption of data, but also encryption of user network connections and stored procedures.